ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group02b.txt/000045_icon-group-sender_Mon Sep 23 19:48:10 2002.msg

Internet Message Format | 2003-01-02 | 13KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8O2lAw02390
    for icon-group-addresses; Mon, 23 Sep 2002 19:47:10 -0700 (MST)
Message-Id: <[e-mail]>
Date: Fri, 20 Sep 2002 09:07:52 -0400
From: "Steve Graham" <[e-mail]>
To: <[e-mail]>
Subject: Moving from Procedural to Object-Oriented (Was Re: Icon Wish
    List)
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id g8KD8Ww18598
Errors-To: [e-mail]
Status: RO

Andrew's post rings close to home, as my division is considering a move from a procedural language to an object-oriented one.  Accepting that on the one hand a LARGE system may benefit from the benefits of the object-oriented approach, while not forgetting that fads occur in all walks of life, including programming, I would appreciate if anyone in this group has seen the benefits vs the costs of moving from procedural to OO.  Maybe also the "be sure to avoid" things.  For my part, I see the advantage of hiding data and reusing code, but this can be done with structured code and well-crafted libraries.

TIA, Steve

===

>>> "Andrew Hamm" <[e-mail]> 09/18/02 09:57PM >>>
Frank J. Lhota wrote:
> Looking over the last several versions of Icon, the last several
> versions did little more than adding a few functions and fix a few
> bugs. It has been a while since there have been major enhancements to
> the Icon language. This type of stagnation harms Icon's long term
> prospects. It is time to consider some major upgrades to Icon.
>

I've been watching this debate with interest (and am heartened by the
increase in traffic above zero messages a month...) so here's my $0.04(AU)
[current exchange rate is $1.00AU = $0.54US]

> 1) Object-Oriented Programming

Yes, Idol is very interesting, but I haven't used it in any project, just
dabbled. I have used Icon for a few large tools; 3 of them are an essential
part of the software development production system in my company.

The simplest one is a pre-processor in the style of cpp, which we can use
with our 4GL (sql-based) source code. This is a relatively simple process,
and objects could have been convenient to store things like the defines and
the stack of the pre-processor blocks, however lack of OO did not cause any
difficulty.

The second major tool is a 4GL code generator. It reads form specification
files, accesses the database for table schema, and generates 4GL. Given the
large number of source instructions representing screen objects and business
rule actions, OO would have been very useful indeed and I did find myself
wishing for classes *with methods* to get around my regular confusion as I
got deep into nasty expressions which could only exploit . and [ ]
operators. Not a few bugs were caused by mistakes with access to deep object
members and performing work on them.

The 3rd major tool is a source code merger, which reads a bunch of
instructions to insert, replace or delete code blocks in the generated 4GL
(this allows our programmers to maintain regenerable forms and yet perform
powerful modifications to the generated code, to suit the exact business
needs). This tool exploits the amazing power of coroutines amongst other
things, and I managed to achieve a remarkable O(N) processing time. It's
remarkable because I wrote it to replace a 3rd-party tool which slowed
quadratically vs code size. This process had middling need for OO but once
again exploited the magic of Icon to achieve its task.

It's when projects achieve a critical mass that OO becomes a benefit. Any
educational sample of OO fails to prove the need for OO IMHO. I still desire
OO in Icon and forsee no costs beyond the implementation effort. I really
can't see OO degrading Icon; with proper design it should fit in very nicely
and elegantly. Apart from the corruption caused by it's pre-processing
nature, Idol does show what is possible. With integrated support, the rough
edges of Idol could be cleaned up.

It's interesting to think about the style of the syntax to use. Given that
OO is only really useful for large projects, I would lean towards the "one
file, one class" approach, which means that the classes could look like
this:

<file foo.icl>   # just a suggestion

class Foo [ : superclass ... ]

define var, var, var ...

static classvar, classvar ...

constructor Foo( arg ... )
    ....
end

destructor ~Foo( )
   # typical destructor stuff
end

method instanceMethod( arg ... )
    ...
end

static method classMethod( args )
    ...
end

</file>

NOTE: use of "constructor", "destructor" and "method" keywords does not
denote a preference.

Since Icon is completely free with variable types and call arguments, it
follows that class members should not be typed, and overloaded methods do
not make sense either - one name, one method. A class constructor is
obviously needed, and presumably a class destructor too; for the usual
application-level cleanups. Due to the nature of Icon garbage collection,
the destructor would not be called at any predictable time, but then, people
comfortably live with that in Java.

There's probably scope for operator overloading. Icon has a decent set of
operators, and some tasks benefit from operator overloading - however,
people do tend to get very silly trying to squeeze as much as possible into
that mould ;)

What about member privacy? With the 1 file, 1 class model, it does become
possible to add a "private" keyword for class methods, members and statics.
If marked as private, the member is not visible outside the file. However,
that does not fit at all with the dynamic typing of Icon. How do you know
the type of a particular variable at any one time? You don't, so you can't
block access to specific fields, unless some sort of runtime check was added
to provide the illusion of privacy. Perhaps that's acceptable... If the
runtime check was provided, then presumably protected member access could
also be fitted. Personally I wouldn't fuss deeply about this. The Perlish
idea of the "gentleperson's agreement" works for me.

Should member variables be accessible with the usual . notation? Or should
objects *only* allow either readonly access to variables, with all
assignments applied only in the class source file? Presumably, identifiers
would be looked up thru the local declarations (and method args) then class
variables, then finally globals. So it could be reasonable to say that
Obj.varname is simply not assignable. Very easy. However, that would make
even classes suspicious of themself:

class Foo;

define Bar;

method Baz( )
    local other

    other := expression-yielding-Foo-object
    other.Bar := 1    # ERROR!!!!! dang
    other.setBar(1)  # works, but ugly
end

Hence, I would keep away from that and invoke the Gentlecodesters agreement
again...

With the current Icon runtime, the interpretation of obj.member would
actually need to resolve to an internal object just like the pending array
(or is it string?) assignments (sorry, my implementation book is at home and
it's been 5 years since I last read it anyway). Since obj.field (and indeed
obj[index]) could be variously interpreted as

    rec.field, or
    class.field, or
    class.static, or
    class.method

depending in the dynamic type of obj, the . operator in the runtime would
need extending so that if the left arg is an object, the field is looked up
via the class. If the field is found as a member variable, then it probably
could yield an assignable item just like rec.field, but if the field is
found to be a method, then it should yield a new variant on the proc - a
special block which also records the sender. In theory, it's entirely
possible to pass this thing around before using it:

    mc := obj.method
    foo(mc)
    ....
procedure foo(mc)
    x := mc(arg1, arg2)

Simply because obj.method needs to have ( ) stuffed on the end before the
actual call is applied. In normal practice of course, that is what would
usually happen:

    val := obj.method(arg1, arg2)

but the internal implentation is simple and interesting because of it.

What else? Inheritance? OK...

Sure, multiple inheritance. Circular like Idol? Why not! Very interesting
idea and I don't see why the compiler needs to drown in a sea of infinite
recursion if decent programmers work on it ;-) What about if two supers have
the same super, leading to a diamond structure?

class A
class B : A
class C : A
class D : B C

What did Idol do? Merge? I don't remember. But Idol is probably a good
guide. How's this for an alternative: Since OO is best for large projects,
the Eiffel concept of "redefine" and "rename" are very appealing. Not only
do these two clauses eliminate most of the anti-multiple inheritance
arguments, it also solves a less talked-about problem, where a parent class
might be extended by adding a new method or member, which subsequently
conflicts silently with a subclass member of the same name. There is
responsibility in this direction also...

The redefine and rename clauses eliminate the need for messy syntax which is
needed to access overridden parent members. If they are overridden they can
be made available through a different name so there is no need for nonsense
like super::method( ... ).

With the rename and redefine clauses, you are expected to know and declare
redefinitions. In large projects, that's a very powerful safety feature. How
could this work in Objective Icon? The compiler will collect a class
definition. An optional list of parent classes might be found, with optional
redefine or rename clauses, along with member variables and methods. The
compiler would collect all these items in good faith, and build the
intermediate code as it does now, assuming that the linker and runtime will
make more sense of it all.

The linker would then take on a greater role. All the class definitions need
to be banged together; insert Tab A into Slot B and so on. At this point,
the inheritance trees (graphs) will be constructed. I would propose that
each class definition will have a private member list built, so that the
runtime system does not need to travel the tree each time a member is
accessed. A simple lookup of the member in the objects class will be
sufficient to find it's offset within the object and it's type etc.

Back to the class traversal: For each class, visit all the parents looking
for extra members and methods to attach to the class. Any conflicts which
are in violation of the rename and redefine clauses can be found at this
time. Therefore the class tree could be shown to be correct by the linker.
By this time, everything is resolved, the final .icx is written and we're
ready for the real fun to begin.

Is that enough? I've proposed something very simple, requiring only a few
new internal block types to represent the classes, the objects, and the
mutated proc blocks (sender.method). I've relied upon a Gentle-programmers
agreement for all the usual fuss about protection, encapsulation etc.
Runtime traversals to find methods can be avoided.

What about abstract classes and abstract methods? What about them? I suppose
they are possible; in fact, a redefine clause without a corresponding method
definition will implicitly be an abstract method. Is this any use? I would
guess that an abstract method would merely be a null member in the class
lookup table. Icon currently supports this (and provides a runtime error) if
you attempt a call to a non-existent method. This is probably a very
appropriate response for OO too.

> 2) Better Interfacing to External Programs
>
>[SNIP]
>
> Nevertheless, other languages provide ways of calling external
> functions and handling external memory. Why can't Icon have these
> abilities?
>

Why not indeed? Perl's XS facility does a very good job. Of course, the C
code must comply. Perl does offer a usable malloc and free which means it's
quite easy to link in 3rd party libraries which may not assume they'll be
linked into Perl. Icon/XS will need the same respect for 3rd-party
libraries. The XS framework generator is a very useful tool for Perl, and
points to the need for something similar with Icon.

> 3) Unicode Support
>

Don't care ;-) I guess we should all get into the 21st century sooner or
later...

> 4) Icon as a Scripting Language
>

Interesting idea. In principle, some simple hack can already be done using
hash-bang lines and possibly a bit of disguised shell-code. Isn't there an
icont argument which asks for automatic execution of the resulting object?
If there isn't it can surely be added.

To do this "properly" on UNIX, the compiler could probably write to a tmp
file (not linked into a directory) and then hand the open file handles off
to a cooperating iconx which can slurp up the icode from the tmp file
handles and then close them, resulting in their deallocation. This is a very
simple improvement to the compiler and runner, and I wouldn't really class
this as an extension to Icon, because it's more mechanical than anything
else.